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10 



In recent years, the amount of content protection systems has grown at a rapid 
pace. Some of these systems only protect the content against illegal copying whHe others are 
also prohibiting iJie user to get access to the content. The first category is called Copy 
Protection (CP) systems and has been traditionally the main focus for Consumer Electronics 
(CE) devices, as this lype of content protection is tiiought to be implementable in an 
inexpensive way and does not need bi-directional interaction with the content provider. 
Examples are CSS (Content Scrambling System), tiie protection system of DVD ROM discs 
and DTCP (Digital Transmission Content Protection), the protection system for IEEE 1394 
connections. The second category is known under several names, m the broadcast world they 
are generally known as CA (Conditional Access) systems, while in Ihe Internet world they 
are generally known as DRM (Digital Rights Management) systems. 

Content protection systems normally involve protected communication 
between devices based on some secret, only known to devices that were tested and certified 
to have secure implementations. Knowledge of the secret is tested using an authentication 
protocol. The best solutions for these protocols are those which employ pubUc key 
cryptography, which use a pair of two different keys. The secret to be tested is then 1he secret 
key of the pair, while tiie public key can be used to verify tiie results of flie test. To ensure Ihe 
corredness of the public key and to check whether the key-pair is a legitimate pair of a 
certified device, the public key is accompanied by a certificate, tiiat is digitally signed by a 
20 Certification Authority (CA), the organization which manages the distribution of 

pubUc/private key-pairs for all devices. Everybody knows tiie CA's public key and can use it 
to verify the CA's signature on the certificate. In a simple inq>lementation the pubUc key of 
the CA is hard-coded into the implementation of the device. 

To enable this process each hardware device or software appUcation (referred 
to collectively as devices hereafter) holds a number of secret keys, sometimes also known as 
private keys. These keys and the control flow using these keys should be weU protected, for 
knowledge of these keys or manipulation of the control flow would allow hackers to 
circumvent the content protection systems. 
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In typical security scenarios , there are several different devices involved, 
which imght not all be implemented with equal levels of tamper-proofing. Such a system 
should therefore be resistant to the hacking of individual devices, which might enable illegal 
storing, copying and/or redistribution of digital content However, it is likely that during the 
Ufetime o f a product type that makes use of the system, some or even many devices wiU get 
hacked in some way. 

An important technique to increase the resistance is the so-called revocation of 
these hacked devices. This requires aU devices to i^ad a so-called Certificate Revocation List 
(CRL), a Kst allowing identification of revoked devices. Compliant devices are forced in 
some mamier to possess an i^-to-date CRL, and Ihey should never pass content to devices 
that axe Hsted as revoked in the CRL. The CA generates and distributes new CRLs whenever 
necessary. 

Revocation can be indicated in several different manners. Two different 
techniques are to use so-called black lists (a list of revoked devices) or white lists (a list of 
un-revoked devices). Typically all devices in the content protection system have mutuaUy 
unique identifiers installed in the factory. Alternatively an authorized domain manager device 
may assign unique identifiers to devices as they join the authorized domain. These identifiers 
can be used in the CRL instead of globally unique identifiers. 

The difference between white lists and black Usts lies in their interpretation 
and use: in order for a "Verifier" to ascertain that a "Prover^' wishing to authenticate with the 
Verifier is indeed not revoked, in the case of black lists, the Verifier will have to obtain the 
complete blacklist. In the case of white liste, the Verifiers need as proof of non-revocation 
only that part of the white list that refers to the PubKc Key or ID of the Prover. Therefore the 
while list scenario has in5>ortant advantages in terms of storage and bus-transmission in 
content protection systems, especially in scenarios such as a PC-host application 
authenticating to a peripheral device like an optical drive with little computing power: 
processing. 

However, with this advantage comes a disadvantage: simple white-listing 
requires that every device/application gets its own certificate attesting to its state of non- 
30 revocation, with enormous network, or disc-storage overhead. 

To mitigate this problem, international patent application WO 003/107588 
(attorney docket PHNL020543) and international patent appKcation WO 003/107589 
(attorney docket PHNL020544) introduced a Groups Certificate (GC) that is supplied by the 
Prover to the Verifier. The GC is a concise proof of the feet that one or more groups-to one 
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of which the Prover belongs— is authorized, for example to access certain content under the 
control of the Verifier or to perform some other operation like logging in to a network. This 
same CJC can be usedby many devices/application (in feet all devices/appUcation which are 

mentioned in the GC). 

The group certificates according to these patent appHcations indicate in one 
embodiment the upper and lower boundaries of each group represented in the GC. When a 
device in a particular group loses its status as authorized device, one or more new group 
certificates have to be generated. Moreover to indicate these boundaries the device identifiers 
are included. Such identifiers can be very large since they often have to be globally unique. 
This makes groiq> certificates quite big if there are a large number of groups. Also, parsing 
these group certificates maybe difficult, especially by hardware devices with Uttle memory 
and computing capaxaty. 



It is an object of the present mvention to provide a method of generating an 
autiiorization status Ust which provides on flie average a shorter representation of flie 
autiiorizatian status of the devices on the list than prior art methods. 

This object is achieved according to the invention in a method comprising 
generating a run-length encoded representation of an authorization status of a number of 
devices and storing the representation in the authorization status fist. 

The invention is based in part on the following insights: 

- Witii very high probability, recently manufactured devices IDs will be unrevoked. 

- Software devices are more vuhierable to hacking tiian hardware. Old software devices 
are very likely to have the status "revoked". 

- When revocation occurs, it wiU involve legal action. This represents a substantial 
tiireshold and therefore the number of revocation events will be limited. Furthermore, 
the probable outcome of such le^ revocation actions is that a single device or a 
contiguous range of devices (e.g. a modeVtype &om the same manufacturer or 

software company) will be revoked. 

- Theftmayoccurofdiscscon1ainingnewdeviceIDsM)hcKeys/PrivateKeys 

(typically a block of numbers) for distribution to drive manufecturers and software 
companies. When this Iheft is discovered, the Certification Authority revokes all tiiese 
(contiguous) device IDs. 

As a result, authorization status lists are expected to contain: 
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- long ranges of unrevoked devices, 

- long ranges of revoked devices, 

- isolated single revoked devices between long ranges of unrevoked devices, and 

- isolated single unrevoked devices between long ranges of revoked devices. 
Run-length encoding will ensure these long ranges of devices all with the 

same authorization status are efficiently represented. 

In an embodiment Ihe method comprises generating the representation by 
indicating, for each of a number of ranges of devices, the devices in aparticular range having 
a same authorization status, the number of devices in each of said ranges. This is a veiy 
efficient way to perform run-lengflx encoding of authorization status information that does not 
require a lot of processing power for the decoding. 

Preferably in the authorization status list for each of said ranges the 
authorization status shared by the devices in each of said ranges is indicated. This can be 
done using a single bit, e.g. the hmary value '1' indicates the device is not authorized and the 
1 5 binary value '0' indicates the device is authorized. 

Preferably in the authorization status list for each of said ranges a boundary of 
the ranges is indicated, for example a device identifier lowest and/or highest in the ranges. If 
the ranges are consecutive, the lowest identifier of the lowest range and/or the highest 
identifier of the highest range can be used. This makes it clear to which devices the list 
20 applies. 

The list may indicate for plural ranges the respective numbers of devices m 
each of fliose ranges. If a second range is successive to a first range, then it should be ensured 
that the first aufliorization status differs firom Ihe second aufliorization status. This provides a 
very efficient run-lengfh coding, because now it is possible to omit the indication of ibe status 
information. If the status of one range is known, then the statuses of all others can be derived 
by their ordering relative to the one range. 

Preferably a range is omitted if it is of a predetermined length. Short ranges of 
revoked devices, especially ranges of length one (i.e. individual revoked devices) are more 
likely to occur than long ranges. Hence, by omitting indications of such ranges a substantial 
saving can be achieved. A device parsing the Ust can derive the status of the device(s) in such 
a range because it will be preceded and followed by ranges having the same au&orization 
status. This can only occur if there was a range with opposite authorization status, and hence 
that range must have been omitted. 
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These and other aspects of the invention will be parent from and elucidated 
with reference to the iUustrative embodiments shown in the drawings, in which: 

Fig. 1 schematically shows a system comprising devices interconnected via a 

network; 

Fig. 2 schematically shows a server arranged to generate an authorization 

status list in accordance with the invention; 

Fig. 3 illustrates a preferred implementation of an authorization status Ust; 

Fig. 4 schematically shows an exemplary embodiment of the invention in 
which a source device authenticates a sink device; and 

Fig. 5 schematically shows a challenge/response protocol to establish a Secure 
Authenticated Channel (SAC) which involves the use of an autiiorization status list in 

accordance with the invention. 

Throughout the figures, same reference numerals indicate similar or 
corresponding features. Some of tiie features indicated in tiie drawings are typically 
implemented in software, and as such represent software entities, such as software modules 
or objects. 



Fig. 1 schematically shows a system 100 comprising devices 101-105 
interconnected via a network 110. A typical digital home network includes a number of 
devices, e.g. a radio receiver, a tuner/decoder, a CD player, a pair of speakers, a television, a 
VCR, a digital recorder, a mobile phone, a tape deck, a personal computer, a personal digital 
assistant, a portable display unit, and so on. These devices are usually interconnected to allow 
one device. e.g. tiie television, to control anotixer, e.g. tiie VCR. One device, such as e.g. tiie 
tuner/decoder or a set top box (STB), is usually tiie centiial device, providing cential control 
over the otiiers. 

The system 100 may be an in-home network that operates as an Autiiorized 
Domain. In tins kmd of content protection systems (like SmartRight ftom Thomson, or 
DTCP from DTLA) a set of devices can auflienticate each otiier tiirough a bi-directional 
connection. Based on tins autixerxtication, tiie devices will tiiist each otiier and tiiis will enable 
tiiem to exchange protected content. In tiie ticenses accompanying tiie content, it is described 
which rights tiie user has and what operations he/she is allowed to perform on tiie content. 



-P HN L04 0 332 EP Q- 



15 



^ 17.03.2004 
Some particular architectures of authorized domains have been outlined in 
intemationaJ patent application WO 03/09893 1 (attorney docket PHNL020455), European 
patent application serial number 03100772.7 (attorney docket PHNL030283), European 
patent application serial number 03102281.7 (attorney docket PHNL030926), European 
5 patent application serial number 04100997.8 (attorney docket PHNL040288)'and 

F. Kamperman and W. Jonker, P. Lenoir, andB. vdHeuvel. Secure cont^t management in 
authorized domains, Proc. IBC2002, pages 467-475, Sept. 2002. Authorized domains need to 
address issues such as authorized domain identification, device check-in, device check-out, 
rights check-in, rights check-out, content check-in, content check-out, as well as domain 
10 management. 

Content, which typically comprises things like music, songs, movies, TV 
programs, pictures, games, books and the likes, but which also may include interactive 
services, is received through a residential gateway or set top box 101. Content could also 
enter the home via other sources, such as storage media like discs or using portable devices. 
The source could be a connection to a broadband cable network, an Internet connection, a 
satellite downlink and so on. The content can then be traasferred over the network 1 10 to a 
sink for rendering. A sink can be, for instance, the television display 102, the portable display 
device 103, the mobile phone 104 and/or the audio playback device 105. 

The exact way in which a content item is rendered depends on the type of 
device and the type of content. For instance, in a radio receiver, rendering comprises 
generating audio signals and feeding them to loudspeakers. For a television receiver, 
rendering generally comprises generating audio and video signals and feeding those to a 
display screen and loudspeakers. For other types of content a similar appropriate action must 
be taken. Rendering may also include operations such as decrypting or descrambling a 
25 received signal, synchronizing audio and video signals and so on. 

The set top box 101, or any other device in tiie system 100, may comprise a 
storage medium SI such as a suitably large hard disk, allowing the recording and later 
playback of received content. The storage medium SI could be a Personal Digital Recorder 
(PDR) of some kind, for example a DVD+RW recorder, to which the set top box 101 is 
connected. Content can also enter the system 100 stored on a carrier 120 such as a Compact 
Disc (CD) or Digital Versatile Disc (DVD). 

The portable display device 103 and the mobile phone 104 are connected 
wirelessly to the network 1 10 using a base station 1 1 1, for example using Bluetooth or ffiEE 
802.1 lb. The other devices are connected usmg a conventional wired connection. To 
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allow the devices 101-105 to interact, several interoperability standards are available, which 
allow different devices to exchange messages and information and to control each other. One 
well-known standard is the Home AudioA^ideo Interoperability (HAVi) standard, version 1 .0 
of which was published in January 2000, and which is available on the Internet at flie address 
http://www.havi.org/. Other well-known standards are the domestic digital bus (D2B) 
standard, a communications protocol described in lEC 1030 and Universal Plug and Play 

(http://www.upnp.org). 

It is often important to ensure that the devices 101-105 in the home network 
do not make unauthorized copies of the content. To do Ms, a security ftamework, typically 
referred to as aDigital Rights Management (DRM) system is necessary. One way of 
protecting content in the form of digital data is to ensure that content will only be transferred 

between devices 101-105 if 

- the receiving device has been authenticated as being a compliant device, and 

- the user of the content has the right to transfer (move and'or copy) that content to 
another device. 

If transfer of content is allowed, this will typically be performed in an 
encrypted way to make sure that flie content cannot be c^tured iUegally in a use&l format 
from the transport channel, such as a bus between a CD-ROM drive and a personal computer 
(bost). 

Technology to perform device authentication and encrypted content transfer is 
available and is called a secure authenticated channel (SAC). In many cases, a SAC is set up 
using an Authentication and Key Exchange (AKE) protocol that is based on pubHc key 
cryptography. St^dards such as Intemational Standard ISO/IEC 11770-3 and ISO/IEC 9796- 
2, and pubhc key algorithms such as RSA and hash algorithms like SHA-1 are often used. 

Fig. 2 schematically shows a server 200 arranged to generate an authorization 
status Ust in accordance with the invention. This list can then subsequently be used by 
devices such as the devices 101-105 to verify whether flieir communication partners are still 
authorized to communicate with them. 

The invention assumes that devices have respective identifiers. These 
identifiers are arranged in a particular ordering. A very straightforward way to do this is to 
assign the first device the identifier "1", the second the identifier "2", and so on. If the device 
identifiers themselves are noncontiguous, for example if they are randomly chosen 
alphanumerical strings, a mapping could be made to a sequential ordering. 
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The authorization status Ust reflects the authorization status of a number of 

devices. This number of could be all devices, but is preferably chosen as a subset. If chosen 
as a subset, it is advantageous to indicate in the Hst one or both boundaries of the subset, for 
example the lowest and/or highest device identifiers or the lowest device identifier togeflier 
with an indication of the size of the subset. 

The subset can be chosen to correspond to apredefined groi^ of devices. For 
example a group of devices manufactured by the same entity, or in aparticular period could 
be covered by a single authorization status list. 

For each appHcable device identifier the authorization status is determined. 
This status can be as simple as "authorized" versus "not autiiorized" or be more complex. For 
example, an authorization status list could indicate that a particular device should no longer 
be communicated with at all. or that only content of low value should be supplied to that 
particular device. If a simple two-state status is used, a single bit can be used in the 
authorization status list to represent it. The server 200 may comprise a database 210 
indicating the authorization status of the devices for which the authorization status list is to 
be generated. 

When a device is "authorized" or not depends on the appKcation. It could 
mean that it has been established that the device is in compliance with a certain set of 
requirements or a certain standard. It could mean that the device is aufliorized to access, 
copy, move, modify or delete certain content that it may perform some other operation like 
logging in to a network. 

The server 200 then activates run-length encoding module 220 to generate a 
run-length encoded representation of these authorization statuses. In api^ferred embodiment, 
the module 220 identifies ranges of devices having the same authorization status. A range is a 
set of successive items in Ihe ordering used for the device identifiers. The module 220 might 
for example determine that devices with identifiers 1-53 are authorized, devices 54-69 are not 
authorize4 device 70 is authorized, devices 71 -89 are not authorized and devices 90-100 are 
authorized. For each range the module 220 then generates an indication of the number of 
devices in that range. In the example of the last paragraph, the server 200 would indicate in 
the authorization status list the numbers 53, 16, 1, 19, 11. It is clear that this form of run- 
length compression presents a large reduction compared to indicating for each of these 100 
devices their status separately. 

The encoded representation is then fed to list generation module 230, which 
creates an authorization status Ust comprising this encoded representation. Preferably the 
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module 230 indicates wifli each nmnber the appUcable status, for example "1: 53, 0: 16, 1: 1, 
0: 19, 1: 11". Alternatively an indication could be provided, for example in Ihe header, of the 
authorization status of liie first range indicated. A device parsing this list can then assume 
that the second range has a status opposite to Ihe indicated status, the Ihird range a status 
equal to the indicated status, the fourfli again opposite and so on. This has the advantage that 
only a smgle status indication needs to be provided even when a large number of ranges is 
included. 

It might be agreed upon beforehand that the first range indicated is always to 
be considered authorized or not authorized. This means lhat not even a single status 
10 indication needs to be provided. However, this creates the problem that the first device in the 
first range might eventually come to have an authorization opposite to the agreed-upon status. 
To solve tihis problem this first identifier could be declared reserved so that it will never be 

assigned to any devices. 

For example, suppose it is agreed upon fliat the first range indicated is always 
15 to be considered authorized. In the beginning, all devices are authorized so that the 

authorization Ust could be as simple as "1 -100". At some point in time the first ten device 
identifiers are to be declared no longer autiiorized. A new authorization Hst is tiien generated, 
mdicating "1, 10, 89". This can be interpreted as "the first ten device identifiers are not 
authorized e^d ihe next 89 are autiiorized", since tiie very first mdication covers only tiie 

20 reserved device identifier. 

A further improvement can be obtained by omitting a range of predetermined 
lengtii. Preferably this predetermined lengtii is chosen to be equal to 1 . It may be desirable to 
indicate in tiie autiiorization status list tiie value of tins predetermined lengtii. In tiie example 
under discussion, omitting ranges of lengtii 1 would result in indication of "1: 53, 0: 16, 0: 

25 19, 1 : 1 1" in tiie list. The omitted range can be detected from tiie fact tiiat tiiere have been 

indicated two consecutive ranges witii tiie same autiiorization status. If tiiere were no devices 
in between witii a different status, tiiese two ranges could have been indicated as a single 
range. 

The number of devices in a particular range can be indicated using a fixed 
30 number of bits. It may be advantageous to have tiie module 230 determine what tiie highest 
number is and to determine flie number of bits needed to represent tins number. This number 
of bits can tiien be indicated in flie Hst. This avoids tiie situation tiiat for example 32 bits are 
used to encode each number of devices in each particular range, of which 16 are wasted 
because no range comprises more tiian two to tiie power of 16 devices. 
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Multiple lists might be combined into a single data element, so that such an 
element covers multiple nonconsecutive ranges of device identifiers. In this case the header 
of the data element might provide an indication of the respective ranges covered, for example 
"1-100, 120-140, 250-290". This allows easy filtering by devices receiving this data element. 

The module 230 might digitally sign the authorization status list or protect it 
otherwise, for example by attaching a keyed message authentication code (see Ihtemet RFC 
2104). 

Fig. 3 illustrates a preferred implementation. The authorization status of aU 
devices ranging from "first address" to "last address" has been determined and is shown at the 
top. There are seven ranges, five of which are labeled nl through n5. The remaining two are 
ranges of length 1, indicating single devices between longer ranges. The length of these 
ranges, together with thek applicable status is indicated in the authorization status list shown 
at the bottom. Each range and status is indicated using a single word that may be 8, 16 32 or 
64 bits. This number of bits might be indicated in the header. The most significant bit ^SB) 
of each word is used to indicate the authorization status of the devices in the corresponding 
range. The other bits of each word are used to indicate the length of these ranges. Ranges of 
length 1 have been omitted. 

Optionally the authorization status list can have a monotonically increasing 
generation or version number, and the devices using the list could then be configured to only 
accept a Hst if its generation nmnber is Mgher than some pre-ordained number, e.g. stored 
among the content on a disc, or stored in NVRAM on board of the device. As alternative to 
such a number, a creation date can be used. 

Havmg generated the authorization status list, the server 200 needs to make 
the information on the hst available to the devices 101-105. This can be done in a variety of 
ways. The server 200 could transmit the list to the devices 101-105 as a signal via a network 
usmg network module 240, for example on request from the devices 101-105. The list could 
also be transmitted periodically. A device that receives the list from the server 200 could 
transmit the list to other devices to which it is connected. It is preferred that when devices 
receive authorization status lists, the devices store only the list concerning the group of which 
they are a member and, accordingly, there is a need for only limited storage size. 

The server 200 could also record the list to a storage medimn, for example an 
optical record carrier such as a DVEH-RW disk. The medium can then be supplied to devices 
101-105. This medium could also hold contend or be dedicated to flie storage of authorization 
Status lists. 
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If the medium is of the rewritable variety, it is preferred to record the Ust in an 
area that ordinary consmner-grade rewriter devices cannot modify. Such an area is sometimes 
known as a "fixed data area", e.g. as disclosed in intemational patent appUcation WO 
01/095327. To store data in such a fixed area requires the use of components which are 
typically not available in consumer devices. An example of atechnique is to make use of a 
"wobble", a radial deviation of the pit positions or the pregroove fix>m a perfect spiral on 
optical disks. Other examples of data stored in fixed data areas are the BCA code proposed 
for DVD-ROM, selectively damaged spots on the disc material burned by hi^-power lasers, 
or data stored in a special area of the disc which contains read-only material. 

Intemational patent application WO 01/095327 also discloses a solution to the 
problem that Ihe authorization status list might be too large to fit in such a fixed data area. A 
cryptographic summary, such as an MD5 or SHA-1 hash, of the authorization status list is 
confuted and recorded in the fixed data area. Since such a summary is very short (typically 
128 or 1 60 bits), it can fit easily in the fixed data area. The larger Hst itself can then be 
1 5 recorded in Ihe rewritable area(s) of tide disk. The Ust is only accepted by a compliant device 
if a summary computedby the compUant device matches the summary recorded m the fixed 

data area. 

m an alternative solution to this problem, WO 01/095327 suggests to record 
identification dala, e.g. arandom number, in Ihe fixed data area. The authorization list, a 
20 cryptographic summary thereof and flie identification data are digitally signed or protected by 
a message authentication code and stored in the rewritable area(s) of the disk. 

The server 200 is typically embodied as a computer system operated by an 
entity referred to as Trusted Third Party (TTP), Key Issuance Center (KIC) or Certifymg 
Authority (CA). Such a computer system operates independently firom the network 100. In an 
alternative embodiment one of the devices 101-105 in the network 100 operates as the server 
200 by generating the authorization status Ust. Preferably the device operating as authorized 
domain manager generates flie authorization states Ust and makes it available to the other 

devices in the authorized domain. 

The authorized domain manager might receive an authorization statos list or 
30 revocation Ust in a non-compressed form or m another form that is not suitable for 

distribution to the devices in the domain. Such a list can potentially be very large, and the 
network 100 might have Umited bandwidth capabiUties, or some of flie devices 101-105 
might have Umited processing capabilities and be unable to process such a large list. In cases 
Uke that it is advantageous that the authorized domain manager generates an authorization 
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status list in accordance with the present invention from authorization information received 
from an external source. 

This generating of a "local" authorization status list could be done by selecting 
from the "global" authorization status list only that information which appHes to devices in 
the domain. The domain manager might know for example which device identifiers the 
devices in the domain have. It can then scan the global list for those identifiers and generate a 
local authorization status list covering those identifiers. The domain manager might digitally 
sign the local authorization status list or protect it otherwise, for example by attaching a 
keyed message authentication code (see Internet RFC 2104). This allows the devices in the 
network 100 to accept the local authorization status list as authentic. 

The domain manager may have assigned the devices that joined the domain in 
a local device identifier. In that case, the local authorization status list could be based on 
these local device identifiers instead of the global device identifiers. This has the advantage 
that local device identifiers are typically chosen from a smaller range than global device 
identifiers, which means that the authorization status list will now be much smaller. 

In a further optimization scheme, the message part of the certificate is 
compressed. Signatures of messages with length m < C can have the property that the 
message can be retrieved from just the signature itself! Naively one might think that it is no 
longer necessaiy to include the group-IDs themselves into the message-part of the certificate 
However, filtering certificates, i.e., decidmg which certificate must go to which device, e.g. 
by a gateway device, becomes then very difficult/costly, because signature processing Is very 
expensive and would have to be done for every certificate. 

To help such a filtering device the following is proposed: the message part of 
the certificate only needs to contain the "lowesf ' and "highest" group-IDs present in the 
group-of-groups (where "lowest" and "highest" are determined relative to the ordering 
relation). This allows flie filter to decide whether this certificate might contain a relevant 
group-ID. This can then be verified by the destination device itself inspecting the signature. It 
allows the rapid rejection of the bulk of certificates that are irrelevant. 

An exemplary embodiment in which a source device authenticates a sink 
device is illustrated in Fig. 4. In Fig. 4, the source device is a DVD reading/writing 
(DVD+RW) drive 41 0 installed in the sink device which is a personal computer 400. The 
source device 410 controls access to content 425 such as a movie recorded on a DVD disc 
420. An appUcation 430 running on the personal computer 400 wants to access this content 
425. To this end it must communicate with the source device 410, typically via the operating 
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system 440 which interfeces between the various components in the personal computer 400. 
As the content is protected, the source device 410 will only grant the requested access if it 
can successfidly authenticate the sink device 400. Granting access may involve supplying the 
content over a bus in the personal computer 400 to the application 430 in protected or in 

5 unprotected form. 

As part of the authorization of access to the content 425, the usage rights 
information may need to be updated. For example, a counter indicating how many times the 
content may be accessed may need to be decreased. A one-time playback right may need to 
be deleted or have its status set to 'invalid' or W. A so-called ticket could also be used. 

10 See US patent 6,601,046 (attorney docket PHA 23636) for more information on ticket-based 
access. THis updating of the usage rights may be done by the source device 410 or by the sink 
device 400. 

In tiiis authentication process, the source device 410 verifies tiie revocation 
status of the sink device 400. To this end it comprises an autiiorization status checking 
15 module 415, typically embodied as a soflware program. The authorization status checking 
module 415 parses tiie authorization status list to determine wheflier fee sink device 400 is 
authorized. To do this tiie module 415 must know a device identifier for tiie sink device 400. 
The sink device 400 may have presented a certificate signed by an autiiorily tirusted by tiie 
source device 410, which certificate contained tiiis device identifier. Otiier ways to learn a 
20 device identifier are of course also possible. 

The module 415 tiien selects an autiiorization status Ust which covers tiiis 
device identifier, for example by parsing a header of tills list to determine wheflier fliis device 
identifier is comprised between tiie lowest and highest device identifiers indicated in tiiis 
header. The necessary autiiorization status list may be obtained in a variety of ways. It may 
25 have been suppUed by tiie sink device 400. It could have been read ftom a storage medium. It 
may have been received from tiie server 200, for example in response to a request by tiie 
device 410. 

In a preferred embodiment tiie "prover" (flie sink device 400) presents two 
digitally signed certificates: tide latest autiiorization status Kst, which shows tiiat a group of 
which tiie prover is a member, has not been revoked, and a certificate (installed in tiie 
factory), tiiat confirms its Device ID (i.e., tiiat tiiis device is a member of tiie group 
mentioned in tiie step regarding tiie latest revocation message). 

Typically, such a certificate contains a Device ID i and a pubUc key PKi. An 
attacker having intercepted a certificate for a group of which i is a member and tiying to now 
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impersonate i, wiU not have the secret key SKi corresponding to PKi and all &rther 

communication will be aborted when this is detected by the verifier. 

Subsequently the module 415 determines in which range the device identifier 
fells. This can be done in many ways. One way is to determine an offset between this device 
identifier and the lowest device identifier applicable to Ihe authorization status list in 
question. The module 415 then can add up the lengths of the ranges as given in the list until 
the some reaches or exceeds Ihe offeet Another way is to add the lengths of the ranges to the 
lowest device identifier applicable until the sum equals or exceeds ihe device identifier for 
tiie smk device 400. In botii cases, tiie range whose lengfli was last added to the sum tiien is 
the ^plicable range. 

In case ranges of predetermined length ate omitted flie module 4 1 5 needs to 
add fliis piedeteimmed length whenever it encounters a second range having ihe same 
autiiorization status as tiie range whose lengtii just was added to the sum. 

A preferred way to implement autiiorization status lists is now discussed. 
Autiiorized CJroups Lists (AGLs) are distidbuted by a Key Issuance Center. An AGL shows 
tiie autiiorization status of all Devices and Applications (witii ID = 0...2'«'.1). The AGL is 
divided into Autiiorized Groups Certificates (AGCs). Each AGC covers a subrange of flie 
AGL, viz. range of devices with contiguous IDs. 

The autiiorization status of tiie devices in tiiis range is specified in each AGC 
listing tiie run lengtiis of intervals in which tiie autiiorization status for IDs is identical Each 
run length is preceded by a 1 -bit flag tiiat specifies flie status (0 = Autiiorized to establish a 
SAC, 1 = otiier). The "otiier" status can indicate e.g. tiiat a device has been revoked or its 
Status is unknown. 

To encode short runs eflBcientiy, two consecutive runs with tiie same flag 
value shall indicate fliat a short mterval witii flie opposite status exists between tiie two runs. 
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The AGCSeqNo field conteins liie Sequence Number of the AGC. The First 
address is the ID of flie first device covered in the AGC. The Last address is the ID of the last 
device covered in the AC3C. The number of bytes that is to be used for the description of run 
lengths is specified by the AGC_Format field. 

A SAC shall be established using a chaUenge/response protocol shown 
schematically in Fig. 5. In tiie first step of this protocol, the Host and the Device exchange a 
challenge. The challenge contains Certificates and a random number. In tiie second step, both 
the Host and the Device check tiie autiiorization of tiie otiier's Public Key Certificate (PKC) 
by verifying tiiat tiie ID, contained in tiie PKC, appears on a vaUd AGC. Valid in tiiis context 
means tiiat a sequence number denoted as ProverAGCSeqNo is greater tiian or equal to a 
sequence number denoted as VerifierSeqNo, whereby tiie Verifier checks the freshness of an 
AGC providedby tiie Prover and wheflier tiie ID of tiie Prover PKC is actually covered by 
tiie AGC. Botii Device and Host alternately ftdfill tiie role of Verifier/Prover. On every disc, 
an Autiiorized Groups List (AGL) is stored. The AGL contains a complete set of AGCs, 
provided by tiie KIC. A VerifierSeqNo can be obtained from several sources: 

- discs 

- other compliant devices 

- network connections 

20 In tiie tiiird step, botii tiie Host and tiie Device generate a response to tiie 

challenge. Subsequently, botii tiie Host and tiie Device check tiie received response. 
Auflientication is success&l only if tiie response is correct. In tiie last step, botii tiie Host and 
tiie Device calculate a Bus Key from data in tiie response. Only tiie Device and tiie Host 
know tiie Bus Key. The Bus Key is used to encrypt data tiiat is transferred over tiie SAC after 
25 completion of the SAC estabHshment protocol. 

It should be noted tiiat tiie above-mentioned embodiments illustirate ratiier tiian 
limit tiie invention, and tiiat tiiose skilled in flie art will be able to design many alternative 
embodiments witiiout departing from tiie scope of tiie appended claims. 

International patent plication WO 01/42886 (atiiomey docket PHA 23871) 
30 discloses an efficient way of combining a contact list and a revocation list Contact Usts can 
be combined witii revocation lists according to tiie present invention. 
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To allow Oprospective) owners of such devices to deteimine the revocation 
status of their equipment, the method according to international patent application WO 
03/019438 (attorney docket PHNLO 10605) can be used. 

European patent application serial number 04100215.5 (attorney docket 
PHNL040086) describes a method of and source device for authotiang access to content by a 
sink device in accordance with usage rights, the content being stored on a storage medium 
controlled by the source device. The revocation status of the sink device is verified using the 
most recently issued revocation information that is available if the usage rights need to be 
modified as part of the authorization of access to the content, and using revocation 
information associated with the content stored on the storage medium, preferably the 
revocation information stored on the storage medium, otherwise. The revocation information 
on the storage medium, or only the part relating to the sink device, is optionally updated to 
the most recently issued revocation information if the usage rights need to be modified. 
Preferably this is done only if the result of the verification is that the sink device has been 
revoked. The revocation information as used in this patent application could be prepared in 
accordance with the present invention. 

In the claims, any reference signs placed between parentheses shall not be 
construed as limiting the claim. The word "comprising" does not exclude the presence of 
elements or steps other than those Hsted in a claim. The word "a" or "an" preceding an 
element does not exclude the presence of a plurality of such elements. The invention can be 
implemented by means of hardware comprising several distinct elements, and by means of a 
suitably programmed computer. 

In the device claim enumerating several means, several of these means can be 
embodied by one and the same item of hardware. The mere feet that certain measures are 
recited in mutually different dependent claims does not indicate that a combination of tiiese 
measures cannot be used to advantage. 
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CLAIMS: 



1 A method of generating an authorization status list, comprising generating a 

run-length encoded representation of an authorization status of a number of devices and 
storing the representation in the authorization status list. 

2. The method of claim 1 , comprising generating tiie representation by 
indicating, for each of a number of ranges of devices, tiie devices in a particular range having 
a same authorization status, tiie number of devices in each of said ranges. 

3. The metiiod of claim 2, comprising indicating in tiie autiiorization status Ust 
for each of said ranges tiie autiiorization status shared by tiie devices in each of said ranges. 

4. The metiiod of claim 2 or 3, comprising indicating in tiie autiiorization statiis 
list a boundary of said ranges. 

5. The metiiod of claim 4, comprising indicating as boundary a device identifier 
lowest and/or highest in the ranges. 

6. The metiiod of any previous claim, comprising generating tiie representation 
by indicating, for a first range of devices, tiie devices in tiie first range having a same first 
autiiorization stetiis, tiie number of devices in flie first range, and, for a second range of 
devices, tiie devices in the second range havmg a same second autiiorization status, flie 
number of devices in the second range. 

7. The method of claim 6, the second range being successive to tiie first range 
and tiie first autiiorization status differing firom tiie second autiiorization status. 

8. The metiiod of claim 6, comprising omitting a fiirtiier range if tiie furtiier 
range is of a predetermined length. 
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9. The method of claim 8, in which the predetennined length equals one. 

10. The method of claim 8, comprising indicating in the authorization status list 
the predetermined length. 

5 

11. The method of claim 2, comprising indicating in the authorization status list a 
number of bits used to indicate the number of devices in each of said ranges. 

12. The method of any previous claim, comprising indicating in the authorization 
1 0 status list a version number and/or a creation date. 

13. The method of any previous claim, comprising transmitting the authorization 
status list to a device for enabling the device to verify the authorization status of itself or of a 



15 



further device. 

14. The method of any previous claim, comprising recording the authorization 
status list on a storage medium 

15. The metiiod of claim 14, comprismg recording tiie authorization status Ust in a 
20 fixed data area of a rewritable storage medium. 

16. The method of claim 14, comprising recording the authorization status list in a 
rewritable area of a rewritable storage medium and recording a cryptographic summary of the 
autiiorization status list in a fixed data area of said rewritable storage medium 

25 

17. A device arranged for executing the metiiod of claim 1. 

18. A ^o^P^ter program for causing a processor to execute tiie metiiod of claim 1. 

30 19. A source device (410) arranged for authorizing an operation by a sink device 

(400), the source device comprising autiiorization status checldng meaas (415) for verifying 
tiie autiiorization status of tiie sink device using an autiiorization statiis list as produced by tiie 
method of claim 1. 
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20. A record carrier on which there is recorded an authorization status Ust as 
produced by the method of claim 1 . 

21. The record carrier of claim 20, comprising a fixed data area and a rewritable 
data area, in which the authorization status Ust is recorded in the fixed data area. 

22. The record carrier of claim 20, comprising a fixed data area and a rewritable 
data area, in which the authorization status Ust is recorded m the rewritable area and a 
cryptographic suimnary of the authorization status list is recorded in the fixed data area. 

23 A signal embodying an authorization status list as produced by the method of 

claim 1. 
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ABSTIIACT: 



A method of generatmg an authorization status list, comprising generating a 
run-length encoded representation of an authorization status of a number of devices and 
storing the representation in the authorization status list. Preferably comprises generating the 
representation by indicating, for each of a number of ranges of devices, Ihe devices in a 
particular range having a same authorization status, the number of devices in each of said 
ranges, toge&er with for each of said ranges the authorization status sharedby the devices in 
each of said ranges. A range may then be omitted if it is of a predetermined length. 
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